Streaming reproduction is a technology for starting reproduction of data before completion of reception of the whole data from a server and continuing it in parallel with the reception of the data, when a client requests data transfer to the server.
Some examples of the data streaming technology currently in use are RealAudio(Trademark), RealVideo(Trademark) and RealPlayer(Trademark) of the Progressive Networks (Seattle, Wash.).
As a means to highly compressing data today, there are ATRAC3 (Adaptive Transform Acoustic Coding 3) (Trademark), MP3 (MPEG Audio Layer 3), etc., capable of realizing much higher compression rate compared to conventional data compression formats.
The streaming reproduction process may be regarded as consisted of a download process from a network, a buffering process of the download data in a terminal and a reproduction process of the buffered data.
Regarding the download process, there are some problems such that buffering time varies depending on the network instability, etc., however, some means to avoid quality loss in the reproduced data has been devised for buffering for mobile information devices.
That is, it is possible to assure stable reproduction quality and to optimize the time to start the reproduction of the music by parameterizing a degree of download instability and the transmission capacity of the network indicating the required time for buffering, and setting an optimum threshold value for the parameters.
The following patent document 1 has a description of the invention related to data download from a server and streaming reproduction by an information-terminal device.
In streaming reproduction, reproduction will stop unless a data transfer rate is larger than a data consumption rate by the reproduction, because the reproduction will outpace the transfer of the data. Accordingly, it is required to take a large data transfer rate for streaming reproduction. In the streaming reproduction, however, if the transfer rate is too large by contraries, buffer overflow may occur when large data in excess of internal buffer size implemented by the client side is requested and transferred at one time, the data overflows in the buffer, causing data loss of the overflow data. To avoid this situation, it is necessary to request the server to send a part of data at a time and repeat the request many times. In the streaming reproduction, however, such a highly frequent request may result in the increased ratio of redundant data such as header information, etc., causing degraded data transfer efficiency or delay in the response time after request. And consequently, in the streaming reproduction, reproduction may also catch up with the data transmission, causing the reproduction to halt, etc.
Such problems are especially apparent for the mobile information devices often with limited memory size to use for an internal buffer, and for data download under such transmission conditions as the Internet with unstable transmission rate.
FIG. 9 shows an example of the streaming reproduction procedure in the patent document 1.
First, the information terminal device calculates the first request size (S11). Next, the information terminal device requests the server to transfer partial data of this calculated request size (S12). After that, the information terminal device starts receiving the data (S13), waits for buffering of a prescribed amount of data (d0) (S14) before starting reproduction (S15). Then, the information terminal device continues the following processing until all downloaded data are reproduced (S16). The amount of the entire data can be recognized by the information terminal device beforehand by the information from the server prior to starting download.
The information terminal device determines whether all the partial data requested this time was acquired on not in the following step S17. The information terminal device returns to the previous step S15 until all of the partial data is acquired. After all the partial data requested at the time is acquired, the information terminal device calculates the request size at the time (S18). If the request size of the remaining data to be transferred from the server is less than the request size (Yes in S19), the information terminal device requests to transfer the remaining data (S21). Otherwise (No in S19), the information terminal device checks the size of the data remaining in the buffer (br) (S20). The information terminal device goes back to the step S15 and continues the reproduction until the remaining amount becomes less than the threshold value. When the remaining data in the buffer (br), which is not reproduced yet, becomes smaller than the threshold value, it is indicated that the request size R1 becomes larger than the predefined size. In the step S15 processing, coming back from the step S20, the information terminal device does not perform the reception processing, since it has finished the reception of the partial data of the previous request.
When the size of the remaining data in the buffer becomes less than the threshold value in the step S20, the information terminal device requests the server to transfer the subsequent partial data of the request size (S21). Then, the information terminal device goes back to the step S15 and performs the reception and reproduction in parallel.
It is described that with this streaming reproduction method, reproduction can be started immediately in response to user's request, and efficient data transfer can be realized by effectively using the limited buffer capacity to request the server to send a part of the data sequentially for one download for streaming reproduction of the downloaded data.
Patent document 1: Japanese Patent Application Laid-open No. 2002-215516 (Paragraph No. [0036] to [0039], FIG. 6)
However, when expanding the compressed data in the buffer at the information terminal device, it is not possible to assure reproduction quality or proper time to start reproduction if the threshold value is decided without taking account of the compression rate of the data to be reproduced, since the expanded data size will be different case by case, depending on the compression rate.
Besides, if the threshold value for starting reproduction is fixed only for a particular compression rate, the reproduction quality and the time to start reproduction will be varied depending on each music, for the data to be reproduced from the compressed data that is transmitted in varied compression rate, for the information terminal device that reproduces music with variable compression rate.
Moreover, since the application software for reproducing the compressed data generally has different requirements for the reproduction start time depending on each application, it was difficult to assure reproduction quality and to optimize the memory resource without taking account of the compression rate of the reproduction data.